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Abstract — This article describes our strategy for deploying 
self-forming ad hoc networks based on the Internet Protocol 
version 6 and evaluates the dynamics of this proposal. Among 
others, we suggest a technique called adaptive routing that 
provides secure intelligent routing capabilities to computer com- 
munication networks. This technique uses the flow label, supports 
hybrid metrics, network load sharing, and is not restricted to 
evaluation of performance on first hop routers when making 
routing decisions. Selective anycasting is an extension to the 
anycast addressing model that supports exclusion of members 
of groups that perform poorly or inappropriately on a per-host 
basis. Distributed name lookup is suggested for integrating self- 
forming and global networks where they coexist. At last, we pose 
an address hierarchy to support unmanaged discovery of services 
in unknown networks. 



I. Introduction 

SELF-FORMING ad hoc computer networks [1] will be- 
come an active research field in the coming years. As 
other self-organizing networks, these networks are able to 
respond to hostile actions such as Denial of Service (DoS) and 
Distributed Denial of Service (DDoS) attacks more efficiently 
than traditional networks. This ability is useful for deploying 
unmanaged computer networks. Self-forming networks are 
an adequate platform to deploy proposals like intelligent au- 
tonomous agents [2] that require some degree of survivability 
in the network infrastructure. 

A fault tolerant network like the one suggested above 
requires intelligent routing capabilities and a technique for 
discovering and allocating resources in a unmanaged and non- 
centralized way. Requirements include: 

• Reliable, fault tolerant, communication networks support- 
ing an intelligent routing framework and redundancy; 

• Discovery of devices offering services in a dynamic 
networking environment, in an unmanaged way; 

• Integration with existing network infrastructures where 
available, supporting a world-wide reaching technique; 

• Automatic configuration of devices; and, finally, 

• A secure network infrastructure. 

In this paper we propose a technique, called adaptive 
routing, that provides secure intelligent routing capabilities to 
computer networks at an autonomous system (AS) level. This 
technique, based on the use of the flow label field, resolves 
the security issues associated with other routing proposals in 
a simple and elegant way. Selective anycasting increases the 
robustness of anycast addressing, enabling hosts to selectively 
reject those members of anycast groups that do not fit their 
requirements but are still alive. 

The most important contributions of this manuscript are 
the development of a secure intelligent routing infrastructure 
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for computer communication networks, and an extension to 
anycasting that significantly increases the robustness and reli- 
ability of this addressing model. Discovery of services and a 
distributed name lookup mechanism, presented initially in [3] 
for the automatic configuration of IPv6 devices, is applied to 
self-forming networks. 

The remainder of the paper is organized as follows. In 
Section mi we introduce related work. Section |lll| describes the 
notational conventions used in this article. Section Hvl outlines 
our proposal for deploying self-forming ad hoc networks at a 
theoretical level. Section |V| provides a performance evaluation 
of our prototype when compared with current fixed networks. 
Section |Vl| presents the security weaknesses commonly found 
on ad hoc networks and, more specifically, self-forming net- 
works, and how our proposal manages those security issues. 
Some possible research lines are shown in Section fvTTI Finally, 
conclusions are outlined in Section IVIIII 

II. Related Work 

The Internet Protocol version 6 (IPv6) [4], [5] is a good 
foundation for deploying self-forming computer networks. 
This communication protocol provides hierarchical addresses 
and is a key element for supporting safe intelligent routing 
using the flow label field. This section provides an overview 
of research efforts related with our proposal. 

• The Dynamic Host Configuration Protocol (DHCPv6) [6] 
allows passing configuration parameters such as network 
addresses, netmasks, and hostnames to network nodes 
from a DHCP server. 

• The flow label field [7] enables classification of packets 
belonging to a specific stream by the {label, src, dst) 
triplet. This field can be used by the packet classifier in 
a router to efficiently forward traffic for a particular data 
stream. As routers do not need to parse the option head- 
ers, packets can be processed faster, increasing effective 
routers throughput. 

• Intelligent route controllers [8]-[10] are appliances that 
make routing decisions for multi-homed connections im- 
plementing route changes in Border Gateway Protocol 
(BGP) [11] routers. Currently, non-BGP routing is a cost 
effective solution for networks that do not want to run a 
routing protocol as complex as BGP. An intelligent route 
controller optimizes traffic routed from a subset of the 
Internet address space to a set of non-overlapping regions 
called clusters. 

• The Internet Control Message Protocol (ICMPv6) [4] 
REDIRECT messages are used by routers to inform other 
nodes of a better first hop toward a destination. Con- 
sidered harmful by security concerned sites, REDIRECT 
messages are not honored by most routers. 
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TABLE I 

NOTATIONAL CONVENTIONS USED IN THIS PAPER 



Symbol Definition 
V = {po]P1tP2, • • • tPu) set of parameters that define the 
requirements* of a packet stream; 
Pi is the weight of the i-th parameter 
7^* — ^ . . . ^r\^.} i-th route discovered in the ad hoc network; 

is the j-th intermediate system in the 
route; Ui is the number of intermediate 
systems in that route 
Ti Tj link between intermediate systems and rj 

w'^(po;pi,P2, . . . ,Pn) total cost of the i-th route 
Wj(pi,p2, . . . ,Pn) cost of the j-th intermediate system, 

^^opt (po ; p 1 , P2 , • • • , Pn ) lower cost found 

For example: bandwidth, latency, number of hops... 

• The routing extension header [12] is an IPv6 header 
option used to route packets, either strictly or loosely, 
from a source to a destination host. It is assumed that, 
as the ICMPv6 redirect messages, the routing header 
is a security concern as a consequence of a lack of an 
authentication mechanism. 
As a difference with intelligent route controllers, we propose 
making intra- AS routing decisions. Our proposal is intended to 
complement, not to replace, intelligent route controllers. From 
all the above, we conclude that both the ICMPv6 redirect 
messages and the routing extension header are not adequate 
mechanisms to achieve intelligent routing. Instead, we suggest 
using a secure mechanism to modify the interface to which a 
flow label is assigned. 

III. NOTATIONAL CONVENTIONS 

Let us define the set of intermediate systems in the i-\h route 
discovered by the route servers as TV = {rl^rl^ . . . ^rl^.}, 
where is the j-th intermediate system in this route. Routes 
are calculated to minimize the cost, , for a set of parameters 
^ = (Po;Pi,P2, . . . ,Pn). In this paper r^+i denotes a 

link between intermediate systems and r^+i. This link is not 
bidirectional; in other words, r^+i ^ is a different link in 
our simulation. We pose the notation ^ r^+i to denote both 
links simultaneously. A brief outline of notational conventions 
used in this manuscript is provided in Table |l| 

IV. Adaptive Computer Networks 

One of the goals of a self-forming ad hoc computer network 
is being able to response to a changing environment (e. g., 
degrading softly under a DoS attack). Both automatic discov- 
ery of services and adaptive routing are powerful tools for 
responding to the challenges introduced by dynamic network 
topologies. The former is based on the use of reliable any cast 
groups and service oriented IPv6 addresses; the latter on route 
servers (RSes) and flow labels. We suggest using a distributed 
name service for integration between self-forming and fixed 
networks. This naming service allows nomadic networks to be 
reachable without using tunnels. The use of a local namespace 
on each device for allocating services discovered simplifies 
application management. 



A. Discovery of Services 

As outlined in [3], anycasting [13], [14] with service 
oriented IPv6 addresses^ can be used to build a framework 
for the automatic discovery of machines offering services. 
The unicast addresses of those machines can be added to 
local namespaces in each self-configurable device to simplify 
configuration of applications. Selective anycasting, described 
below, can greatly improve reliability of any cast addressing. 

B. Overlay Networks 

Distributed name lookup (DNL) [3] is a name resolu- 
tion technique useful for reaching nodes of a self-forming 
nomadic network where access to a global communication 
infrastructure is possible. DNL splits name resolution in two 
tasks that will run on probably different nameservers. In fact, 
DNL makes forward resolution in the base network (i. e., the 
network of the mobility provider) and reverse translation in 
the network where the mobile devices reside. These temporary 
resource records cannot be transferred to slave nameservers. 

C. Adaptive Routing 

We suggest using RSes, supporting hybrid metrics for route 
optimization, and an intelligent routing based on the flow label 
field. Hybrid metrics allow routing infrastructure to assign a 
cost to each intermediate system that depends on more than 
one parameter. Each parameter can have a different weight in 
the estimation of the cost. 

1 ) Combining Multiple Metrics in a Single (Hybrid) Metric: 
RSes can assign a cost to each intermediate system as a 
function of the requirements for packet forwarding for a 
given data stream (e. g., high bandwidth, low latency, . . .). 
Let us define the total cost i^-^ (po ; Pi , P2 , • • • ,Pn) for a route 
^ {r^,r^,...,r^.} as: 

W^{po;Pl,P2,...,Pn) = ^ + ^^](pi,P2,...,Pn) , (1) 

where V = (po;Pi,P2, • • • ,Pn) is a set of parameters that 
define the requirements of the hybrid metric; in this equation, 

V = min (2) 

l<i<nj 

is the end-to-end effective bandwidth between the source 
and destination hosts (bj is the available bandwidth in the 
intermediate system r^); i^^^ (pi,P2, • • • ,Pn) is the cost^ of 
in the route for V. The best path discovered is the one 
that minimizes the end-to-end cost: 

^opt(po;Pi,P2,...,Pn) = min^^(po;Pi,P2,...,Pn) . (3) 

Table ini shows a subset of end-to-end metrics that can be used 
to calculate the cost of a route between two hosts. 

^ Where the host portion of the IPv6 address has been replaced by a service 
identifier field. 

^po, the weight assigned to the bandwidth requirement, must be applied to 
the effective bandwidth for the end-to-end route. This parameter cannot be 
applied to the throughput on each intermediate system. 
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TABLE II 

Metrics for End-to-End Performance Estimation 



Symbol 



Quantity 



Mathematical Expression 
for this metric 



Units 



available bandwidth^ b^ = mini<^<^ . 6^ 

— — 3 '' 



multiple communication cost 

t delay'' 
At jitter'^ 



I price, 
reliability, 
security, 
etc . . . 

where Af^ =t]—F- is the 



kB-s-i 
N/A 



delay variation in r\ 
Hi number of hops N/A 

^For file transfer protocols. 

"^For interactive applications (e. g., TELNET). 

'^For multimedia streams. 



2) Routing Packets: Intelligent routing can usually be 
abused to gain access to networks whose firewalls are poorly 
configured. Therefore, routing decisions should not be made 
by untrusted third parties (e. g., hosts) but from authenticated 
devices. For adaptive routing, we suggest the use of RSes 
that will try to discover the route that best fits the set of 
requirements V for a data stream between two nodes of the 
self-forming network. These devices must be authorized to 
modify the interface assigned to a flow label on routers. 
Routers supporting this feature are called adaptive routers 
in this article. Adaptive routers can monitor their network 
interfaces looking for communication failures; if a failure 
is detected, adaptive routers can ask an authorized RS for 
an alternative route to the destination host. RSes can use a 
keep-alive mechanism to ascertain the availability of adaptive 
routers. An adaptive router that stops responding to the re- 
quests of a RS is an indication of a network failure too. 

3) Selective Any casting: Let us suppose that one of the 
members of the anycast group is not performing as expected. 
The members of the self-forming network should have a 
chance to reject nodes that are inadequate or deficient. Existing 
keep-alive mechanisms cannot detect members that behave 
poorly or inappropriately but are still alive. Our proposal is 
using a members exclusion header (EH) to provide a list of 
machines that should not be contacted^. To protect clients of 
the self-forming network against variations in the routing path 
as a consequence of changes in the network topology, we 
suggest using the unicast addresses assigned to the members 
of the anycast group instead of its relative position in the 
routing path. Anycast addresses can be translated to unicast 
ones, using either anycast address mapper or the source 
identification option [15]. Each time an entry is added to the 
EH, a new data stream must be established; as a consequence, 
a new flow label is calculated by the source host. This header 
should be under the control of end-user nodes because: 

• Routers are not designed for network analysis; and, 

• Applications have the ability to decide if a member of an 
anycast group is performing adequately, and should have 

^As anycast addresses are assigned to routers [13] to simplify routing, this 
extension header does not require support in the members of the groups. 



a chance to reject those members that does not. 
Selective anycasting is a lightweight extension to the any- 
casting addressing model that does not introduce overhead in 
routing if flow labels are used"^. 

anycast group 

^ routing p ath ^ 

/ ^ c ^ ' 
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Fig. 1. A Fluid Meclianics analogy to Selective Anycasting 



Fig. [l] outlines an analogy between selective anycasting 
and a simple mechanical set-up. Let us suppose that an 
incompressible Newtonian fluid flows in a continuous stream 
on the pipeline described in this figure. Joints in this pipeline 
are comparable to anycast routers. Each duct has a valve that 
acts as a control device for conveying the Newtonian fluid 
in the experimental device. These valves close temporarily an 
orifice that permits the movement of fluid to the "members of 
the anycast group", in the lower part of the figure. Initially, all 
valves are open, allowing the incompressible fluid to convey 
to the nearest member of the anycast group from the point 
of view of the pipeline topology. In our analogy, adding the 
unicast IP address assigned to a member of the group to the 
EH is like closing the valve in the duct that joints that member 
to the main pipeline. Without those valves, the fluid that flows 
on the pipeline has no chance to be carried to other members 
of the anycast group. In our scenario nodes whose IP addresses 
are in the set S = {IPi,IP2, . . . ,IPi_i} had been excluded 
by closing the valves in the ducts that join them to the pipeline. 
These nodes will not be reached until valves are open again 
(i. e., until their addresses are removed from the EH and a 
new packet stream to the anycast group is established). 

V. Experimental Evaluation 

We used the ns Network Simulator [16], [17] for testing 
the proposal outlined in this manuscript. Our prototype was 
developed using the Object Tel [18] programming language, 
an extension to the Tool Command Language (Tel) [19] for 
dynamic object-oriented programming. In this Section, we 
describe the experimental set-up used to test our intelligent 
routing model and provide performance metrics for our pro- 
totype when compared to standard routing proposals. 

A. Description of the Prototype 

The aim of our simulation is estimating the ability of our 
proposal to recover connectivity when compared to standard 
routing algorithms after a part of the network has been 
damaged; consequently, the network topology assures the 
existence of more than one valid route between the source 
and destination hosts. We simulate a damaged link between 

^Flow labels are required for adaptive routing, not for selective anycasting. 
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intermediate systems and rj by turning down the links 
Ti ^ Tj simultaneously. Same failure conditions are applied 
for all routing proposals evaluated in this article. 
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Fig. 3. Throughput for Standard TCP in the first Scenario 
Router Unreachable 



Fig. 2. Changing the Interface assigned to a Flow Label in our Prototype bandwidth (Mb/s) 

Fig. 121 shows how we have implemented the flow label 
updating mechanism in ns. Let us suppose that an intermediate 
system has two output interfaces, r^+i and r^+i, 
both of them valid routes toward a destination host. To route 
traffic to one of these interfaces our prototype turns down all 
the output links except the one that will carry the data stream. 
In this scenario, both r^+i Vi and f^+i remain up 

to allow acknowledgments (ACKs) reaching the host that has 
sent the packets through the link Vi-i. Our simulation 

uses a distance vector (DV) routing algorithm. 



B. Performance Evaluation 

The goal for our routing proposal is not performance but 
reliability. On the other hand, intelligent routing is a powerful 
tool for increasing network performance, allowing routing 
infrastructure to make routing decisions based on a global 
network state, instead of first neighbors feedback. 

Figs. [S] up to [S] illustrates the performance of TCP Reno, 
a selective acknowledgment (SACK) TCP sender, TCP Tahoe, 
TCP Vegas, and our adaptive routing proposal. Fig. |6| depicts 
network dynamics when a permanent link failure is detected by 
an adaptive router and announced to a RS. Scenario outlined 
in Fig. is a variant of the previous one; in this case, 
both a standard router and an adaptive router are unreachable 
after the link failure. A higher delay in recovering network 
connectivity in the self-forming network is observed because 
a new route is not calculated by the RS before the keep-alive 
mechanism ascertains that the adaptive router is not available. 
Finally, Fig. [8| depicts the effect of a short loss of connectivity. 
When the adaptive route detects the network failure it sends 
a request to update the route followed by data streams to a 
RS. Both di fast response (FR) from the RS, received before 
connectivity is recovered, and a slow response (SR), received 
after recovering normal network conditions, are compared with 
the performance of TCP Reno in same network conditions. 

VL Security Considerations 

Joining anycast and multicast groups in a secure manner 
[20], [21] is a requirement for supporting current networking 
services. Authentication of the members of anycast groups 
is required for discovery of services. Selective any casting 
provides reliable and fault tolerant anycast groups. 

Adaptive routing works for self-forming networks with an 
internal packet forwarding mechanism. It is a secure approach 
to intelligent traffic routing because: 




Fig. 4. Throughput for Standard TCP in the second Scenario 
Temporary Link Failure 
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Fig. 5. Throughput for Standard TCP in the third Scenario 

1) The exact route is not under control of network nodes; 

2) Only authorized RSes are able to change the route on 
the routers enabled to support this feature. 

As both authentication of RSes and a relatively updated 
knowledge of network topology is required, intelligent routing 
must be done at an AS level. Contacting with anycast groups 
of RSes in other ASes allows this proposal to be extended to 
a global computer network like Internet. 

VIL Future Work 

We suggest improving the synchronization mechanism be- 
tween adaptive routers and RSes. Detection of changes in the 
network topology as soon as occur is an important goal. The 
development of a keep-alive mechanism between RSes and 
adaptive routers will contribute to detection of network failures 
that isolate adaptive routers from the rest of the network. 

VIIL Conclusion 

Survival from failures in communication infrastructure and 
attacks against networking equipment requires development 
of robust, fault tolerant, computer communication networks. 
This article proposes some techniques to improve reliability of 
current communication frameworks and support construction 
of self-forming ad hoc computer networks. Our main contri- 
butions are: 
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Fig. 8. Throughput for the Flows in the third Scenario 

• The development of an anycast addressing extension to 
allow applications to reject those members of anycast 
groups that are not performing adequately, but are still 
alive; and, 

• A framework, based on IPv6 flow labels, that provides 
intelligent routing capabilities to computer networks. 

Other techniques we have developed in the last years are 
suggested for integration with fixed networks and for the 
unattended configuration of devices. 
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